home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group98a.txt
/
000073_icon-group-sender _Mon Mar 2 08:27:22 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
3KB
Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id IAA27655
for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Mon, 2 Mar 1998 08:27:22 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
id AA01814; Mon, 2 Mar 1998 08:27:21 -0700
Message-Id: <34F76A7A.367B@gte.net>
Date: Fri, 27 Feb 1998 19:38:02 -0600
From: Mark Evans <evans@gte.net>
Reply-To: evans@gte.net
Organization: None
X-Mailer: Mozilla 3.01 (Win95; I)
Mime-Version: 1.0
To: icon-group@optima.CS.Arizona.EDU
Subject: Re: Translation into C
References: <199802270710.BAA08211@axp.cmpu.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Content-Length: 2211
I'm afraid that Gordon Peterson and I will have to agree to disagree
where we seem to part ways. Interpreters are slow by nature compared to
compiled code. My four examples prove it as far as I am concerned.
The time domain hydraulics simulation was a one-for-one port, matrix
multiplies and all...MATLAB is supposed to excel at matrix ops. In
fact, I don't think MATLAB has dynamic typing at all. My Mathematica
image processing ports were one-for-one involving procedural for-loops.
Ditto the LabVIEW work -- and LabVIEW has static typing. No dynamic
type changes in the middle of these loops and matrix ops.
What G.P. says about high-level language overhead and systems language
efficiency is exactly the reason for building a C converter. He expects
C to be faster, and I do too. I guess where we part company is that he
fancies an exception to the rule in the case of "C doing all the same
things." I've done the same things in C and C always wins -- by huge
margins of the kind I mentioned (10x - 50x). Whenever you are doing
things with hardware-mapped instructions, you are faster, even if they
are the same things.
The reason that we are seeing faster and faster processors is not to
make glad those who write interpreters. It's to make glad customers who
are tired of looking at watches and hourglasses and status bars. If the
day ever comes when people don't feel they need more power, then believe
me, they will stop paying for it. Have you ever looked at the markup
difference between Intel's previous-generation and current-generation
chips? It's tremendous; they know the value of their fastest products.
The other argument in favor of a C converter is to enable workers to use
Icon stuff in their projects. If I could get C code out of Icon, then I
could plop Icon modules into my C projects.
I think G.P.'s comment about the expense of programmer hours also argues
in favor of getting a C port system working. It would enable commercial
programmers to get the same functional result in one-tenth the time. In
principle, the C code would be guaranteed accurate by virtue of its
automatic generation. One-tenth the time for more solid code is a
bargain in my book.
Mark